| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
This piece of code actually did nothing except trace!()-printing. Thus, remove
it.
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
This change fixes a bug where two submits that differed only in an
environment variable where considered equal:
butido build pkg
butido build pkg -E FOO=1
the second build reused the artifacts from the first one, which is a
bug.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
Tested-by: Matthias Beyer <mail@beyermatthias.de>
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
This patch adds the ability to have more than one release store.
With this patch, a user can (has to) configure release store names in the
configuration file, and can then specify one of the configured names to release
the artifacts to.
This way, different release "channels" can be served, for example a stable
channel and a rolling release channel (although "channel" is not in our wording).
The code was adapted to be able to fetch releases from multiple release
directories, in the crate::db::find_artifact implementation, so that re-using
artifacts works across all release directories.
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
This patch changes the code so that the MergedStores object is known in the
endpoints and job execution code.
This is necessary, because the jobs must be able to load artifacts from the
release store as well, for example if a library was released in another submit
and we can reuse it because the script for that library didn't change.
For that, the interface of StoreRoot::join() was changed
- -> Result<FullArtifactPath<'a>>
+ -> Result<Option<FullArtifactPath<'a>>>
whereas it returns an Ok(None) if the artifact requested does not exist.
This was necessary to try-joining a path on the store root of the staging store,
and if there is no such file continue with try-joining the path on the release
store.
The calling code got a bit more complex with that change, though.
Next, the MergedStores got a `derive(Clone)` because clone()ing it is cheap
(two `Arc`s) and necessary to pass it easily to the jobs.
Each instance of the code where the staging store was consulted was changed to
consult the the release store as well.
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
This patch fixes a bug in the crate::db::find_artifacts() implementation, which
caused the function to fail if the filesystem object was removed.
For example, if a package X was built and released, but then removed on the
filesystem, this function would try to find that object but fail and cause
butido to stop.
Because that's not what we want, this function does not fail anymore but simply
ignore the not-found object and return nothing for it.
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
Tested-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
This fixes the query, because it must start from the packages table and filter
for package namd and version, and then join the other tables.
The dependency filtering was removed because it was too complex at this points.
Also, the release finding was changed so that the Release object is retrieved
later in the process of artifact selection.
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
|
|
This patch implements the find-artifact subcommand, which is the basis for
artifact finding.
Right now we have the problem that finding artifacts after the fact is non-trivial.
What we can do, though, is search for them in the database using the same inputs
as the ones that created the artifact.
That means that if we want to find an artifact or multiple artifacts for a
package P in version V, we have to search the database for jobs that built that
package in that version, with the same script and the same variables
(environment, used container image, etc).
So if a package was built with the same script, the same environment variables
and on an image that is, for example, not in the denylist of the package,
chances are good that the artifacts produced by the job for the package are the
ones we search for.
In the `crate::command::find_artifact()` function, results are sorted before
they are printed, so that we preferrably print results with a release date.
Env filtering is also implemented, so a user has to provide the appropriate
additional environment variables, as they were submitted for the `buid` command
when the artifact was built.
Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
Tested-by: Matthias Beyer <matthias.beyer@atos.net>
|
