Bamboo cannot publish files to sourceforge!

Community Infrastructure
1

This CI build fails for the stages of publishing files to sourceforge.

I looked at the logs and picked interest in this:

error 06-Oct-2020 19:51:13 Warning: Identity file /home/bamboo-agent/.ssh/id_rsa not accessible: No such file or directory. build 06-Oct-2020 19:51:14 sending incremental file list error 06-Oct-2020 19:51:14 rsync: failed to set permissions on "/home/frs/project/o/op/openmrs/.": Invalid argument (22)

@cintiadr did we make any changes that led to the above error?

2

Just in case @burke has something to say about this.

3

Odd. It looks like the id_rsa is stored under .ssh/sourceforge/id_rsa (not .ssh/id_rsa), but that hasn’t been changed in years.

4

Indeed, this was changed along long time ago.

I believe that just removing the key configuration from the script would work as expected. Otherwise, just use sourceforge key.

5

I changed the rsync command within openmrs-contrib-bamboo and I see the same problem exists in the nightlybuild.sh script within puppet settings for the bamboo agents. But, I think I’m over my head.

Should I have left the username as “openmrsdev,openmrs”? I haven’t seen that syntax before and only the “openmrs” username works for me when I try accessing sourceforge with the key. How was this ever working? I changed the username to “openmrs” here, but not sure if that is necessary/correct. I also haven’t run puppet before and I"m not seeing how openmrs-contrib-bamboo scripts are wired into the bamboo agents (haven’t found a reference to that repo under the puppet folder).

So, I think:

  1. $HOME/.ssh/id_rsa should be changed to $HOME/.ssh/sourceforge/id_rsa in this line
  2. The username needs to be changed back to “openmrsdev,openmrs” in the line I changed or the username in nightlybuild.sh should be changed to “openmrs”
  3. These changes need to somehow get deployed to our bamboo agents.

I’m not quite sure what should happen with #1 & #2 and I don’t know how to do #3 with puppet. :confused:

6

@burke I’m on my way to work, but that repo is cloned by the bamboo build. I think you are right on everything

7

I thought I had to have puppet installed on my machine, but I see now the puppet scripts are run on the agents. So, is this correct?

$ ansible-playbook -vv -i inventories/prod-tier2 \
    --limit "yak.openmrs.org,yokobue.openmrs.org,yue.openmrs.org" \
    -u burke site.yml

Then on each agent:

$ sudo -i
# /etc/openmrs-puppet/bin/pull-changes.sh
# /etc/openmrs-puppet/bin/run-puppet.sh

@cintiadr let me know if I’ve got the right commands. If so, I can do it! :slight_smile:

8

Yes, but you don’t need to run puppet! Just rerun the builds

9

@burke CI will just clone that repository on any new build:

(see ‘release-scripts’ repo). It needs to be a new build, never a rerun (as it will keep same commit hashes)

10

Also, if you changed puppet, you’d only need to run the puppet part. Bamboo agents have a mix of ansible and puppet, so it’s complicated.

11

Thanks @cintiadr. I ran the ansible playbook for the 3 Bamboo agents. Hopefully that will help. I’m still not 100% confident, since the nightlybuild.sh script seemed to have the exact same problem (rsync pointing to .ssh/ instead of .ssh/sourceforge/ and using “openmrs,openmrsdev” as a username for ssh), yet I don’t see any recently missing nightly build artifacts on sourceforge. :man_shrugging:

BTW
 it looks like limiting to multiple servers in my ansible-playbook command above leads to a race condition for the sshd role trying to remove entries locally from known_hosts, causing failed steps on 2 of 3 servers. Running the playbook for one server at a time was more reliable.

12

I have just run a new build and here is the log: https://ci.openmrs.org/browse/OP-PLATFORM-PW-30/log

Of interest is this line: rsync: failed to set permissions on "/home/frs/project/o/op/openmrs/.": Invalid argument (22)

FWIW, despite these failures, the war file and readme have all along being uploaded to sourceforge. But because of these failures, the third release stage does not run and hence the standalone does not get uploaded to sourceforge.

13

Hello @dkayiwa @burke @cintiadr .Have also encountered similar issue trying to release refApp 2.11 with similar log however i was able to release referenceapp distro as seen here am only facing releasing to sourceforge as seen here

14

@sharif if you take a second look at my previous post, you will notice that this failure does not prevent the artifacts from being uploaded to sourceforge. https://sourceforge.net/projects/openmrs/files/releases/OpenMRS_Reference_Application_2.11.0/

1 Like
15

ohhh sure thanks i have confirmed them, however i think will need to resolve this error