On Sat, Jan 04, 2025 at 12:58:34AM -0800, Loren M. Lang wrote:
> On Mon, Dec 30, 2024 at 02:52:26PM -0800, Loren M. Lang wrote:
> > Looks like this Pipeline has been failing since the beginning 2 years
> > ago. It appears like there is some missing dependency on the
> > bash-completion package somewhere along the way for Debhelper that needs
> > to be added, although, it would probably be better for it to just not
> > require bash-completion for an automated build.
>
> OK, I've fixed the issue with the CI failing for gh. The package has a
> build dependency on dh-sequence-bash-completion which requires that the
> bash-completion package to be installed before starting the build. I
> added a before_script section to the CI configuration to install the
> missing package and it is now passing on the build. I also pulled in the
> Salsa CI job that Otto added for building a complete package with the
> normal Debian CI build. The MR is available here:
>
> https://salsa.debian.org/go-team/packages/gh/-/merge_requests/3
>
> I manually started the Salsa CI job after filing the MR, but I see that
> is it stuck waiting for a Runner in the provision stage due to no
> available runners. Otto, is this because this is being run outside of
> the Debian namespace where no runners have been allocated for this
> pipeline?
>
That seems to be the case. I was able to successfully run the Salsa CI
job in my own namespace for gh, but only after enabling Instance Runners
under the CI/CD settings for this repository.
https://salsa.debian.org/penguin359/gh/-/pipelines/791712
I believe the issue is that there are no Runners tagged salsa-ci in the
go-team namespace, just the gi-ci tagged runner used by the existing CI.
Also, Otto, I ran into a separate issue with the conditional added for
the include directive. Since the Docker image used by the
test_the_archive CI job is missing a dependency, I had to add a
before_script section to the top-level YAML file which gets merged into
that job. That worked fine when run under the go-team namespace where
the include is executed, however, it left an incomplete job that lacked
a script, run, or trigger value and caused a hard failure due to the
YAML being invalid.
I tried adding a rule to that job to ignore it, but it still triggered
the YAML error when pushing to my repo. I had to remove it entirely to
get the package stage to run. Adding a dummy script to the job in the
top-level YAML doesn't help because that overrides the script from the
included YAML file. I found that just moving the rule from the include
to the job, it will still do the include, but ignore the job that was
included. This should be a reasonable workaround, but I think moving the
rule into the nested YAML with the upstream job might make more sense.
Here's my current workaround:
diff --git a/debian/gitlab-ci.yml b/debian/gitlab-ci.yml
index d45fc944..d5730208 100644
--- a/debian/gitlab-ci.yml
+++ b/debian/gitlab-ci.yml
@@ -10,16 +10,16 @@ include:
- project: go-team/infra/pkg-go-tools
ref: master
file: pipeline/test-archive.yml
- # Run the Go team CI only in the go-team project that has access to GitLab
- # CI runners tagged 'go-ci'
- rules:
- - if: $CI_PROJECT_ROOT_NAMESPACE == "go-team"
# Install requried prerequisites needed for the job included above
test_the_archive:
before_script:
- apt-get update
- apt-get install -y bash-completion
+ # Run the Go team CI only in the go-team project that has access to GitLab
+ # CI runners tagged 'go-ci'
+ rules:
+ - if: $CI_PROJECT_ROOT_NAMESPACE == "go-team"
Salsa CI:
stage: package
--
Loren M. Lang
lorenl@north-winds.org
http://www.north-winds.org/
IRC: penguin359
Public Key: http://www.north-winds.org/lorenl_pubkey.asc
Fingerprint: 7896 E099 9FC7 9F6C E0ED E103 222D F356 A57A 98FA
Attachment:
signature.asc
Description: PGP signature